[レポート]IAM Roleの一時的な認証情報におけるアイデンティティフォレンジック #TDR444 #AWSreInforce

こんにちは、臼田です。

みなさん、IAMのセキュリティ意識してますか？(挨拶

今回はAWS re:Inforce 2024で行われた下記ワークショップセッションのレポートです。一時的な認証情報を発行するIAM Role(とAWS STS)を調査していく際にAmazon Detectiveを活用するだけでなく、更に深い調査をAmazon Neptuneを利用してグラフDBを構築しNotebookで調査していく内容です。

TDR444 | IAM Roleの一時的な認証情報におけるアイデンティティフォレンジック

AWS セキュリティトークンサービス (AWS STS) は、ユーザーが AWS サービスにアクセスする一般的な方法であり、ロールチェーンを利用して AWS アカウントをナビゲートできます。セキュリティインシデントを調査する場合、履歴と潜在的な影響を理解することが重要です。最初に悪用された認証情報は調査のきっかけとなった認証情報とは異なる場合があり、他のトークンが生成される可能性があるため、1 つのセッションを調べるだけでは不十分な場合がよくあります。また、ロール間の信頼関係により、1 つのセッションの調査では、攻撃者が制御するすべての権限を網羅できない場合があります。このコードトークでは、Amazon Detective を使用してアイデンティティフォレンジック機能を構築し、Amazon Neptune を使用してカスタムグラフデータベースを作成する方法を学びます。

TDR444 | Identity forensics in the realm of short-term credentials

AWS Security Token Service (AWS STS) is a common way for users to access AWS services and allows you to utilize role chaining for navigating AWS accounts. When investigating security incidents, understanding the history and potential impact is crucial. Examining a single session is often insufficient because the initial abused credential may be different than the one that precipitated the investigation, and other tokens might be generated. Also, a single session investigation may not encompass all permissions that the adversary controls, due to trust relationships between the roles. In this code talk, learn how you can construct identity forensics capabilities using Amazon Detective and create a custom graph database using Amazon Neptune.

レポート

アジェンダは以下の通り。

インシデントレスポンスのライフサイクル

インシデントレスポンスのライフサイクルはNIST SP800-61が参考になります。

IAMとSTS

IAMとSTSに付いて理解していきます

IAM Roleはなにかのエンティティがこれを利用して権限を引き受けることが可能です。STSのAssumeRole APIを実行することでこれを引き受けます。AssumeRoleした新しいIAM Roleから、さらに別のIAM RoleにもAssumeRoleできます。これを繋げていくことで複雑な経路を作成し、最終的なアクションを実行していたのは実は誰だったのかわかりにくくなります。

IAM Roleは信頼ポリシー(Trust Policy)により、どのエンティティが引き受けることができるか定義できます。引受元はアクセス許可ポリシーでAssumeRoleの権限と、どのリソースにAssumeできるか設定します。

IAM Roleには2つのポリシーが設定できるので、その性質の違いをよく理解する必要があります。

インシデントレスポンスの際には、IAMリソースの関係性を解明して、何が起きたのか、何ができる状態であったのかを確認していく必要があります。

分析していくためには

すべての動作を理解する必要があります。不正利用されているセッションと最初に漏洩したセッションは別かもしれない。

様々なことを確認していく必要があります。ロールの信頼関係やどちらから利用されているかなど、チェーンを意識する必要があります。

分析していくためには

Amazon Detectiveの仕組みについて。Amazon GuardDutyも含むデータソースから情報を収集してグラフで可視化する。

Finding Groupsによって関係性が解決され可視化と調査が捗ります。

各リソースにフォーカスを当てて関連情報を確認したり、リソースやイベント間での関係性をグラフで可視化できます。

よりカスタムしたグラフを作成する

DetectiveではIAMの関連性を解決して可視化することが可能ですが、先程のようなより複雑なAssumeRoleが行われる場合などの詳細の分析には別の力が必要です。今回は独自の可視化も実装します。

利用するものは以下の通り。

データソースとしてIAMからは信頼ポリシーも取得します。

CloudTrailからは実際に行われたAssumeRoleイベントを取得します。セッションの情報や、特に調査時に有用なIPアドレスやUser-Agentなどの情報も取得します。

Amazon Neptuneを利用します。これはグラフDBのマネージドサービスで、ノードとその関係性を表すエッジで構成されます。

アーキテクチャは以下のようになっています。CloudTrailのログを2つのLambdaが受け取り、種類ごと処理してNeptuneに格納します。

Roles readerはIAM UserやRoleの作成イベントなどを受け取り、Neptuneの情報を更新します。

Assume role handlerはAssumeRoleのイベントを受け取り、情報を更新します。

分析にはJupyter Notebooksを利用します。

実際にやっていきましょう。

コードはこちら、今は処理はあまり書いてありません。

Notebook側ではこんな感じに可視化されています。

処理を書いていきます。UserやRoleを取得していきます。

配置するとこんな感じになります。

さらにこれに関係性を追加してグルーピングしていきます。こんな感じで関係するノードがクラスタ化されて確認しやすくなりました。

まとめ

IAM Roleの調査の難しさと、どうやって調査していくかの指針が参考になるセッションでした。

コードの公開情報などがなかったのですがどこかにあるかもしれません。参考にしてみてください。